Account Abstraction
AA(Account Abstraction)とは?
コントラクトアカウントを最上位アカウント(原語:top-level account)にすること
最上位アカウント:トランザクションの起点となり、その手数料を支払うことができるアカウント
≒ EOA とコントラクトアカウントの差をなくすこと
現状、トランザクションの起点となれるのは EOA のみ
主要 EIP
課題
m0t0k1ch1.icon 綺麗に開発面と運用面で切り分けられるわけではないが
開発面
プロトコルレイヤー改修
大前提として、EIP86 や EIP2938 を実装するためには新しいトランザクション形式や新しい opcode の追加といったプロトコルレベルの改修を行う必要があるが、これには大きなコストとリスクが伴う トランザクションの正当性を再定義する必要がある
トランザクションの正当性がプロトコルによって保証されるものではなくなるため、その検証コストや複雑さを考慮しながら、トランザクションの正当性(どのようなトランザクションであればブロックに含めてよいのか)を定義し直す必要がある
例えば、EIP86 で提案された形式のトランザクションは gas_price = 0 nonce = 0 であるため、マイナーが手数料を支払わないトランザクションや何の効果もないトランザクションを受け入れてしまうリスクが生じる 標準的なトランザクション検証処理を定義し、コントラクトアカウントがそれを有していることを正規表現によって確認できるようしたりすることで対応は可能だが...
運用面
アカウント作成
EOA の作成に gas は不要だが、コントラクトアカウントの作成には gas が必要
mempool 管理
上記プロトコル改修次第では、既存の方法では対応しきれないケースが出てくる?
m0t0k1ch1.icon そもそも既存の方法をわかってないので、想像でしかない
EIP2938 で言及されている multi-tenant AA が取り扱うようなユースケースなど 複数ユーザーによる同一アカウントのステート更新
例えば、複数ユーザーで nonce を共有するような状況を考えてみるとよい
このようなケースを考慮し、EIP2938 では nonce 展性が示唆されている DoS 攻撃対策
マイナーがトランザクションで指定された処理を全て実行せずにその正当性を検証できる必要がある
これが不可能な場合、「大量の処理を行うトランザクションを送信し、処理の最後で revert する」といった攻撃が簡単に行えてしまう
そもそも tx.sender という概念がなくなるため、それを基準とした DoS 攻撃対策が不可能となる
特に、EIP2938 で言及されている multi-tenant AA が取り扱うようなユースケースにおいて ref. EIP2938 で言及されている、verification phase における外部ステート参照にまつわる話 参照